home *** CD-ROM | disk | FTP | other *** search
/ The Arsenal Files 8 / The Arsenal Files Collection #8 (Arsenal Computer) (1996).ISO / pcboard / iemsi120.zip / EMSC-001.001 < prev    next >
Text File  |  1991-05-03  |  53KB  |  1,045 lines
  1.  
  2.     ─────────────────────────────────────────────────────────────────────
  3.  
  4.     Filename......: EMSC-001; Electronic Mail Standards Document #001
  5.     Rev...........: 001
  6.     Date..........: May 3, 1991
  7.     Subject.......: EMSI/IEMSI Protocol Definitions
  8.     Author........: Joaquim H. Homrighausen
  9.  
  10.     ─────────────────────────────────────────────────────────────────────
  11.       Copyright 1989-1991 Joaquim H. Homrighausen. All rights reserved.
  12.     ─────────────────────────────────────────────────────────────────────
  13.  
  14.  
  15.     Notice
  16.     ═════════════════════════════════════════════════════════════════════
  17.     This document obsoletes EMSI_003 and any previous document describing
  18.     the EMSI, UZAP, and/or IEMSI handshake protocol. I apologize for the
  19.     lack of proper state charts. I am currently under a fairly heavy
  20.     work-load and thought it would be better to release something half-
  21.     decent than not to release anything at all.
  22.  
  23.     Restrictions
  24.     ═════════════════════════════════════════════════════════════════════
  25.     EMSI/IEMSI may be used by any developer as long as these
  26.     specifications are followed exactly. The IEMSI and EMSI specifications
  27.     may be implemented independently of each other.
  28.  
  29.     EMSI/IEMSI may be used free-of-charge by any developer for any
  30.     purpose, commercially or otherwise. In creating EMSI/IEMSI, we are
  31.     taking the first step towards developing a clear protocol definition
  32.     for state-of-the-art E-Mail systems to follow.
  33.  
  34.     This document and its NOTES file (EMSI.NOT) may be freely copied and
  35.     distributed, but must NEVER be distributed in a modified form. If you
  36.     have an enhancement request, please contact the author of this
  37.     document; do not change it yourself.
  38.  
  39.     Permission is hereby granted to the FTSC (Fidonet Technical Standards
  40.     Committee) and other technical organisations to republish this
  41.     document in its entirety. Librarians may change the title page and
  42.     page headers to match their library format as long as all copyrights
  43.     and body text remain unaltered. The original document name and source
  44.     (EMSC) must be mentioned in any republished versions of this
  45.     document.
  46.  
  47.     No organization, company, person, or other being may impose any fees
  48.     for any reason for providing this document. This document may not be
  49.     sold or otherwise transferred for personal or company gain under any
  50.     circumstances.
  51.  
  52.     Layout
  53.     ═════════════════════════════════════════════════════════════════════
  54.     This document consists of four major parts; A short introduction and
  55.     explanation of the EMSI/IEMSI handshake protocol, the EMSI
  56.     definitions, the IEMSI definitions, and finally various notes and
  57.     credits.
  58.  
  59.  
  60.     PART I
  61.  
  62.     Introduction
  63.     ═════════════════════════════════════════════════════════════════════
  64.     The EMSI/IEMSI handshake protocol allows for maximum flexibility in
  65.     E-Mail session start-up and control. The YooHoo (FTS-6) standard,
  66.     designed by Wynn Wagner III, was a good idea, but did not allow
  67.     sufficient room for growth and cannot be used in 7-bit environments.
  68.     EMSI/IEMSI should provide for virtually unlimited growth and
  69.     expansion of its own scope. By providing variable-length packets,
  70.     EMSI/IEMSI is capable of being as simple or as complex as necessary
  71.     and entirely backwards compatible when new features and/or protocols
  72.     are added.
  73.  
  74.     All EMSI/IEMSI packets and sequences consists of 7-bit printable
  75.     ASCII characters. This format allows us to establish a universal
  76.     handshake between "PCs" and "mainframes" alike. The more complicated
  77.     the computer system, the more restrictions affect its I/O; there are
  78.     many I/O channels that cannot transmit control characters such as XON
  79.     and XOFF; for this, we have created a universal handshake protocol
  80.     that uses all printable characters.
  81.  
  82.     EMSI/IEMSI does allow control and 8-bit ASCII characters to be
  83.     transmitted. This is, however, accomplished by escaping the data
  84.     and converting it to 7-bit printable ASCII characters.
  85.  
  86.     Data layer
  87.     ═════════════════════════════════════════════════════════════════════
  88.     EMSI/IEMSI is a protocol based on multi-character sequences rather
  89.     than single character flow control. There are several advantages of
  90.     using several characters rather than just one, but there is also a
  91.     drawback. On very poor-quality telephone lines, EMSI will most likely
  92.     require several retransmissions of packets since line noise usually
  93.     come in bursts. That aside, there is little advantage in using a
  94.     protocol based on single characters.
  95.  
  96.     All EMSI/IEMSI sequences are terminated by a single <CR> unless
  97.     otherwise specified. This is necessary to force some data collection
  98.     equipment to flush their buffers. Appending <CR> to EMSI/IEMSI
  99.     sequences in a FidoNet environment is a delicate matter and it is
  100.     important that you follow the notes regarding this.
  101.  
  102.     Note regarding file requests
  103.     ─────────────────────────────────────────────────────────────────────
  104.     The file request concept mentioned in the EMSI document refers to
  105.     WaZOO style file requests as specified in FTS-6. No other file
  106.     request mechanism is supported in the EMSI specifications.
  107.  
  108.  
  109.     Separator usage
  110.     ─────────────────────────────────────────────────────────────────────
  111.     To designate the fields within the EMSI/IEMSI packets and retain
  112.     complete transparency, both start and stop characters are used.
  113.  
  114.     The ASCII1 type is used for all fields within the packet. This uses
  115.     the brace characters to delimit the fields. The '{' (ASCII 123)
  116.     character is the start byte and '}' (ASCII 125) is the stop byte.
  117.     If a stop byte is used as literal data within a field, it must be
  118.     transmitted twice. The end of a field is designated by a stop byte
  119.     that is not followed by another identical stop byte.
  120.  
  121.     The ASCII2 fields are delimited in exactly the same way, but use the
  122.     square brackets as delimiters. The '[' (ASCII 91) is the start byte
  123.     and ']' (ASCII 93) is the stop byte. ASCII2 is used to delimit data
  124.     within the ASCII1 extra_field information.
  125.  
  126.     7-bit data restriction
  127.     ─────────────────────────────────────────────────────────────────────
  128.     It is the developer's responsibility to ensure that the software
  129.     generates EMSI/IEMSI packets and sequences containing only 7-bit
  130.     (00H through 7eH) printable ASCII characters.
  131.  
  132.     It is recommended that all EMSI/IEMSI implementations strip the high-
  133.     order bit of all received characters prior to processing the packet/
  134.     sequence and prior to calculating CRC values.
  135.  
  136.     CRC values
  137.     ─────────────────────────────────────────────────────────────────────
  138.     The polynomial used to calculate a 16-bit CRC is the same polynomial
  139.     used in the Xmodem file transfer protocol. The polynomial used to
  140.     calculate a 32-bit CRC is the same polynomial used in the Zmodem file
  141.     transfer protocol.
  142.  
  143.     Binary values
  144.     ─────────────────────────────────────────────────────────────────────
  145.     Since the EMSI environment specifies only 7-bit printable ASCII
  146.     characters to be used, binary values, such as CRC and length
  147.     descriptors are expressed as a four character hexadecimal string. The
  148.     only exception to this is a 32-bit CRC value which is expressed as an
  149.     eight character hexadecimal string.
  150.  
  151.     The application must treat them case insensitive, eg. ffaa should be
  152.     treated identical to FFAA. 
  153.  
  154.  
  155.     Handling 8-bit data
  156.     ─────────────────────────────────────────────────────────────────────
  157.     Although EMSI only uses 7-bit printable ASCII characters, there is an
  158.     escape mechanism that allows systems to transmit control and 8-bit
  159.     ASCII characters without the requirement of an 8-bit data link. The
  160.     escape character is a backslash character ('\') and is followed by two
  161.     characters in hexadecimal notation. Eg. "\80" is the ASCII character
  162.     128. To insert an actual backslash character, two backslashes are used
  163.     ("\\"), or a backslash followed by the hexadecimal code for a
  164.     backslash, eg. "\5c".
  165.  
  166.     The hexadecimal code following a backslash MUST always be two
  167.     characters, ie. to insert ASCII 15 (hexadecimail 'f'), the result
  168.     would be "0f". All hexadecimal sequences must be treated case
  169.     insensitively.
  170.  
  171.  
  172.     PART II - Electronic Mail Standard Idenfitication
  173.  
  174.     Connecting two EMSI capable systems
  175.     ═════════════════════════════════════════════════════════════════════
  176.     This assumes that the two systems are connected and that no data
  177.     has been transmitted by the Caller.
  178.  
  179.     It should be mentioned that sending/monitoring for the "YooHoo",
  180.     "TSYNC", and other protocol start characters is optional and not
  181.     required for a strict EMSI implementation.
  182.  
  183.     STEP 1, EMSI INIT    
  184.  
  185.         Calling system                   Answering system
  186.     ┌─┬───────────────────────────────┬──────────────────────────────────┐
  187.     │1│ Send <CR> until ANY character │ Send EMSI_REQ and possible       │
  188.     │ │ is received.                  │ banner, etc.                     │
  189.     ├─┼───────────────────────────────┼──────────────────────────────────┤
  190.     │2│ Receive banner, etc. Monitor  │ Monitor line for the EMSI_INQ    │
  191.     │ │ line for the EMSI_REQ         │ sequence and if received,        │
  192.     │ │ sequence and if received,     │ attempt to handshake immediately.│
  193.     │ │ transmit EMSI_INQ and attempt │                                  │
  194.     │ │ to handshake immediately.     │                                  │
  195.     ├─┼───────────────────────────────┼──────────────────────────────────┤
  196.     │3│ No EMSI_REQ sequence received,│ Monitor line for EMSI_INQ and    │
  197.     │ │ send EMSI_INQ twice followed  │ possible other protocol start    │
  198.     │ │ by possible other protocol    │ characters and if received,      │
  199.     │ │ start characters.             │ attempt to handshake immediately.│
  200.     │ │                               │                                  │
  201.     │ │ Transmit <CR>                 │ Go to step 3.                    │
  202.     ├─┼───────────────────────────────┼──────────────────────────────────┘
  203.     │4│ If EMSI_REQ sequence received,│
  204.     │ │ send EMSI_INQ and attempt to  │
  205.     │ │ handshake immediately,        │
  206.     │ │ otherwise repeat step 3.      │
  207.     └─┴───────────────────────────────┘
  208.  
  209.     In steps 1 and 2, both the Calling and Answering system terminate all
  210.     sequences with <CR>. In step 3, the Calling system does not terminate
  211.     sequences with <CR> as it is explicitly transmitted after possible
  212.     protocol start characters. In step 4, the Calling system once again
  213.     terminate all sequences with a <CR>.
  214.  
  215.  
  216.     STEP 2A, RECEIVE EMSI HANDSHAKE
  217.  
  218.     At this point, all sequences are terminated with a <CR>.
  219.  
  220.     ┌─┬──────────────────────────────────────────────────────────────────┐
  221.     │1│ Tries=0, T1=20 seconds, T2=60 seconds                            │
  222.     ├─┼──────────────────────────────────────────────────────────────────┤
  223.     │2│ Increment Tries                                                  │
  224.     │ │                                                                  │
  225.     │ │ Tries>6?                      Terminate, and report failure.     │
  226.     │ ├──────────────────────────────────────────────────────────────────┤
  227.     │ │ Are we answering system?      Transmit EMSI_REQ, go to step 3.   │
  228.     │ ├──────────────────────────────────────────────────────────────────┤
  229.     │ │ Tries>1?                      Transmit EMSI_NAK, go to step 3.   │
  230.     │ ├──────────────────────────────────────────────────────────────────┤
  231.     │ │ Go to step 4.                                                    │
  232.     ├─┼──────────────────────────────────────────────────────────────────┤
  233.     │3│ T1=20 seconds                                                    │
  234.     ├─┼──────────────────────────────────────────────────────────────────┤
  235.     │4│ Wait for EMSI sequence until EMSI_HBT or EMSI_DAT or any of the  │
  236.     │ │ timers have expired.                                             │
  237.     │ │                                                                  │
  238.     │ │ If T2 has expired, terminate call and report failure.            │
  239.     │ ├──────────────────────────────────────────────────────────────────┤
  240.     │ │ If T1 has expired, go to step 2.                                 │
  241.     │ ├──────────────────────────────────────────────────────────────────┤
  242.     │ │ If EMSI_HBT received, go to step 3.                              │
  243.     │ ├──────────────────────────────────────────────────────────────────┤
  244.     │ │ If EMSI_DAT received, go to step 5.                              │
  245.     │ ├──────────────────────────────────────────────────────────────────┤
  246.     │ │ Go to step 4.                                                    │
  247.     ├─┼──────────────────────────────────────────────────────────────────┤
  248.     │5│ Receive EMSI_DAT packet                                          │
  249.     │ ├──────────────────────────────────────────────────────────────────┤
  250.     │ │ Packet received OK?                Transmit EMSI_ACK twice, and  │
  251.     │ │                                    go to step 6.                 │
  252.     │ ├──────────────────────────────────────────────────────────────────┤
  253.     │ │ Go to step 2.                                                    │
  254.     ├─┼──────────────────────────────────────────────────────────────────┤
  255.     │6│ Received EMSI_DAT packet OK, exit.                               │
  256.     └─┴──────────────────────────────────────────────────────────────────┘
  257.  
  258.     All processing of the information in the EMSI_DAT packet must be done
  259.     after transmitting EMSI_ACK twice to the remote system. It is
  260.     recommended that an EMSI_HBT sequence is issued once every seven
  261.     seconds while such processing is taking place to avoid unnecessary
  262.     handshake collissions. Emitting EMSI_HBT should only be done when
  263.     it is obvious that the remote system is waiting for the second phase
  264.     of the EMSI handshake to take place.
  265.  
  266.  
  267.  
  268.     STEP 2B, TRANSMIT EMSI HANDSHAKE
  269.  
  270.     At this point, all sequences are terminated with a <CR>.
  271.  
  272.     ┌─┬──────────────────────────────────────────────────────────────────┐
  273.     │1│ Tries=0, T1=60 seconds                                           │
  274.     ├─┼──────────────────────────────────────────────────────────────────┤
  275.     │2│ Transmit EMSI_DAT packet and increment Tries                     │
  276.     │ │                                                                  │
  277.     │ ├──────────────────────────────────────────────────────────────────┤
  278.     │ │ Tries>6?                        Terminate, and report failure.   │
  279.     │ ├──────────────────────────────────────────────────────────────────┤
  280.     │ │ Go to step 3.                                                    │
  281.     ├─┼──────────────────────────────────────────────────────────────────┤
  282.     │3│ T2=20 seconds                                                    │
  283.     ├─┼──────────────────────────────────────────────────────────────────┤
  284.     │4│ Wait for EMSI sequence until T1 has expired                      │
  285.     │ │                                                                  │
  286.     │ │ If T1 has expired, terminate call and report failure.            │
  287.     │ ├──────────────────────────────────────────────────────────────────┤
  288.     │ │ If T2 has expired, go to step 2.                                 │
  289.     │ ├──────────────────────────────────────────────────────────────────┤
  290.     │ │ If EMSI_REQ received, go to step 4.                              │
  291.     │ ├──────────────────────────────────────────────────────────────────┤
  292.     │ │ If EMSI_ACK received, go to step 5.                              │
  293.     │ ├──────────────────────────────────────────────────────────────────┤
  294.     │ │ If any other sequence received, go to step 2.                    │             │
  295.     ├─┼──────────────────────────────────────────────────────────────────┤
  296.     │5│ Received EMSI_ACK, exit.                                         │
  297.     └─┴──────────────────────────────────────────────────────────────────┘
  298.  
  299.  
  300.     EMSI packet and sequence definitions
  301.     ═════════════════════════════════════════════════════════════════════
  302.  
  303.     ═════════════════════════════════════════════════════════════════════
  304.     EMSI Inquiry                                    **EMSI_INQ<crc16><CR>
  305.     ─────────────────────────────────────────────────────────────────────
  306.     EMSI Inquiry is transmitted by the calling system to identify it as
  307.     EMSI capable. If an EMSI_REQ sequence is received in response, it is
  308.     safe to assume the answering system to be EMSI capable.
  309.  
  310.     ═════════════════════════════════════════════════════════════════════
  311.     EMSI Request                                    **EMSI_REQ<crc16><CR>
  312.     ─────────────────────────────────────────────────────────────────────
  313.     EMSI Request is transmitted by the answering system in response to an
  314.     EMSI Inquiry sequence. It should also be transmitted prior to or
  315.     immediately following the answering system has identified itself by
  316.     transmitting its program name and/or banner. If the calling system
  317.     receives an EMSI Request sequence, it can safely assume that the
  318.     answering system is EMSI capable.
  319.     
  320.     ═════════════════════════════════════════════════════════════════════
  321.     EMSI Client                                     **EMSI_CLI<crc16><CR>
  322.     ─────────────────────────────────────────────────────────────────────
  323.     EMSI Client is used by terminal emulation software to force a mailer
  324.     front-end to bypass any unnecessary mail session negotiation and
  325.     treat the call as an incoming human caller. The EMSI_CLI sequence may
  326.     not be issued by any software attempting to establish a mail session
  327.     between two systems and must only be acted upon by an answering
  328.     system.
  329.  
  330.     ═════════════════════════════════════════════════════════════════════
  331.     EMSI Heartbeat                                  **EMSI_HBT<crc16><CR>
  332.     ─────────────────────────────────────────────────────────────────────
  333.     EMSI Heartbeat is used to prevent unnecessary timeouts from occurring
  334.     while attempting to handshake. It is most commonly used when the
  335.     answering system turns around to transmit its EMSI_DAT packet. It is
  336.     quite normal that any of the timers of the calling system (which at
  337.     this stage is waiting for an EMSI_DAT packet) expires while the
  338.     answering system is processing the recently received EMSI_DAT packet.
  339.  
  340.     ═════════════════════════════════════════════════════════════════════
  341.     EMSI Data                      **EMSI_DAT<len16><data_pkt><crc16><CR>
  342.     ─────────────────────────────────────────────────────────────────────
  343.     EMSI Data is transmitted by both the calling and answering system at
  344.     the appropriate time to exchange system information. Following the
  345.     header is a four byte number representing the length of <data_pkt>
  346.     excluding the CRC and terminating <CR>.
  347.  
  348.     The EMSI_DAT packet is a variable length packet. Since this is a
  349.     synchronous protocol, the inbound data buffer should be purged
  350.     between transmission of the <data_pkt> and <crc16> fields to prevent
  351.     accidental EMSI_NAK sequences, etc.
  352.  
  353.  
  354.     ═════════════════════════════════════════════════════════════════════
  355.     EMSI ACK                                        **EMSI_ACK<crc16><CR>
  356.     ─────────────────────────────────────────────────────────────────────
  357.     EMSI ACK is transmitted by either system as a positive
  358.     acknowledgement of the valid receipt of a EMSI_DAT packet. This should
  359.     only be used as a response to EMSI_DAT and not any other packet.
  360.     Redundant EMSI_ACK sequences should be ignored.
  361.  
  362.     ═════════════════════════════════════════════════════════════════════
  363.     EMSI NAK                                        **EMSI_NAK<crc16><CR>
  364.     ─────────────────────────────────────────────────────────────────────
  365.     EMSI NAK is transmitted by either system as a negative
  366.     acknowledgement of the valid receipt of a EMSI_DAT packet. This
  367.     should only be used as a response to EMSI_DAT and not any other
  368.     packet. Redundant EMSI_NAK packets should be ignored.
  369.  
  370.     The EMSI_DAT packet
  371.     ═════════════════════════════════════════════════════════════════════
  372.     The EMSI_DAT packet is the core of an EMSI negotiated session. It
  373.     contains information vital to the mail session. The following pseudo
  374.     structure shows the layout of the EMSI_DAT packet.
  375.  
  376.     EMSI_DAT
  377.         fingerprint,            "EMSI"
  378.         system_address_list,
  379.         password,
  380.         link_codes,
  381.         compatibility_codes,
  382.         mailer_product_code,
  383.         mailer_name,
  384.         mailer_version,
  385.         mailer_serial_number:    ASCII1;
  386.         extra_field_1,
  387.             ..
  388.             ..
  389.         extra_field_n:            EMSI_addon; (optional fields)
  390.     end;
  391.  
  392.     The EMSI_addon structure is defined as follows:
  393.  
  394.     EMSI_addon
  395.         product_ID,
  396.         specific_data:            ASCII1;
  397.     end;
  398.  
  399.  
  400.     Following is an example of the actual data transmitted as an EMSI_DAT
  401.     packet:
  402.  
  403.     {EMSI}{2:270/17}{}{8N1,PUA}{ZAP,ZMO,ARC,XMA}{44}{AirMail}{0.10}
  404.     {Beta-2}{IDENT}{[Advanced Engineering S.A.R.L.][Luxembourg]
  405.     [Joaquim Homrighausen][-Unpublished-][9600][MO,XA,HST,V32B,V42B]}
  406.  
  407.     EMSI_DAT field definitions
  408.     ─────────────────────────────────────────────────────────────────────
  409.     
  410.     ═════════════════════════════════════════════════════════════════════
  411.     Fingerprint                                                      EMSI
  412.     ─────────────────────────────────────────────────────────────────────
  413.     The constant "EMSI". There is no need for a revision level since this    
  414.     basic format cannot change and remain backward compatible.
  415.  
  416.     ═════════════════════════════════════════════════════════════════════
  417.     System address list
  418.     ─────────────────────────────────────────────────────────────────────
  419.     The system address list is a list of system-specific identifiers for
  420.     the E-Mail system separated by spaces.
  421.  
  422.     For FidoNet-technology based networks, it is required that
  423.     Zone:Net/Node be presented, and .Point be omitted if zero. Zone and
  424.     Net must not be zero.
  425.  
  426.     In other networks, an address such as "jhom@csource.oz.au" should be
  427.     considered valid.
  428.  
  429.     ═════════════════════════════════════════════════════════════════════
  430.     Password
  431.     ─────────────────────────────────────────────────────────────────────
  432.     For systems using a session level password, it would be passed in
  433.     this field. Note that the same password is used for all presented
  434.     addresses and that it must be treated case insensitive.
  435.  
  436.     ═════════════════════════════════════════════════════════════════════
  437.     Link codes
  438.     ─────────────────────────────────────────────────────────────────────
  439.     Link codes is a string of flags that specify desired connect
  440.     conditions. These codes are separated by commas. New codes may be
  441.     added with prior approval from the author of this document.
  442.  
  443.     Calling system/answering system options:
  444.  
  445.         8N1,
  446.         7E1,
  447.         7O2,
  448.         etc.       Communication parameters.
  449.  
  450.     Calling system options:
  451.  
  452.         PUA        Pickup mail for all presented addresses.
  453.         PUP        Pickup mail for primary address only.
  454.         NPU        No mail pickup desired.
  455.  
  456.  
  457.     Answering system options:
  458.  
  459.         HAT        Hold ALL traffic.
  460.         HXT        Hold compressed mail traffic.
  461.         HRQ        Hold file requests (not processed at this time).
  462.  
  463.     ═════════════════════════════════════════════════════════════════════
  464.     Compatibility codes
  465.     ─────────────────────────────────────────────────────────────────────
  466.     Compatibility codes is a string of flags that specifies the
  467.     capabilities and enabled features of the mailer. These codes are
  468.     separated by commas. New codes may be added with prior approval from
  469.     the author of this document.
  470.      
  471.     The calling system must list supported protocols first and descending
  472.     order of preference (the most desirable protocol should be listed
  473.     first). The answering system should only present one protocol and it
  474.     should be the first item in the compatibility_codes field.
  475.  
  476.         Protocols
  477.         ─────────────────────────────────────────────────────────────────
  478.         DZA*    DirectZAP (Zmodem variant).
  479.         ZAP     ZedZap (Zmodem variant).
  480.         ZMO**   Zmodem w/1,024 byte data packets.
  481.         JAN     Janus.
  482.         KER     Kermit.
  483.  
  484.         Other codes
  485.         ─────────────────────────────────────────────────────────────────
  486.         NCP     No compatible protocols (failure).
  487.         NRQ     No file requests accepted by this system.
  488.         ARC     ARCmail 0.60-capable, as defined by the FTSC.
  489.         XMA     Supports other forms of compressed mail.
  490.         FNC     Filename conversion. This indicates that any transmitted
  491.                 files must follow the MS-DOS restrictions of an eight
  492.                 character file name followed by a three character
  493.                 extension; eg. FILENAME.EXT
  494.  
  495.     (*) DirectZAP is a variant of ZedZap. The difference is that the
  496.     transmitter only escapes CAN (18H). It is not recommended to use the
  497.     DirectZAP protocol when two systems are connected via a packet
  498.     switching network, or via another layer sensitive to control
  499.     characters such as XON and XOFF.
  500.  
  501.     (**) The minimum protocol requirement for an EMSI implementation is
  502.     to support plain Zmodem (16- or 32-bit CRC, 1,024 byte packets) which
  503.     is represented by the ZMO flag in EMSI.
  504.  
  505.     ═════════════════════════════════════════════════════════════════════
  506.     Mailer product code
  507.     ─────────────────────────────────────────────────────────────────────
  508.     The hexadecimal representation of the EMSC product code assigned to
  509.     the mailer. Currently, the EMSC codes are the same as the FTSC
  510.     assigned codes.
  511.  
  512.     ═════════════════════════════════════════════════════════════════════
  513.     Mailer name
  514.     ─────────────────────────────────────────────────────────────────────
  515.     Specifies the name of the E-Mail system sending the EMSI packet.
  516.  
  517.     ═════════════════════════════════════════════════════════════════════
  518.     Mailer version
  519.     ─────────────────────────────────────────────────────────────────────
  520.     The version number of the mailer software, ie. "1.10", "2.00".
  521.  
  522.  
  523.     ═════════════════════════════════════════════════════════════════════
  524.     Mailer serial number
  525.     ─────────────────────────────────────────────────────────────────────
  526.     The serial number, distribution source, version information, etc.
  527.     This field is usually displayed like:
  528.  
  529.         Name<sp>Version/Serial_number
  530.  
  531.     eg.
  532.  
  533.         AirMail 0.10/Beta-2
  534.  
  535.     ═════════════════════════════════════════════════════════════════════
  536.     Extra fields
  537.     ─────────────────────────────────────────────────────────────────────
  538.     The extra fields make the EMSI handshake protocol extremely flexible.
  539.     Any program or mailer may add fields to the end of the pre-defined
  540.     structure so that program-specific data may be passed without the
  541.     concern of interferring with other systems.
  542.  
  543.     There may be any number of extra fields added to the end of this
  544.     structure. Each EXTRA_FIELD contains two ASCII1 strings:
  545.  
  546.     PRODUCT_IDENTIFIER      A unique "tag" that defines a specific
  547.                             program (such as a mailer or a utility).
  548.  
  549.     SPECIFIC_DATA           ASCII text that is specific data to the
  550.                             program defined in PRODUCT_IDENTIFIER. With
  551.                             this structure, any program can add its own
  552.                             data to the EMSI packet without affecting
  553.                             other applications.
  554.  
  555.     It is recommended that you contact the author of this document should
  556.     you have any EXTRA_FIELDS that you may think worthwhile for other
  557.     developers to implement and support.
  558.  
  559.     Predefined extra fields
  560.     ─────────────────────────────────────────────────────────────────────
  561.     The following extra fields have been defined to date.
  562.  
  563.     PRODUCT_IDENTIFIER   :  IDENT
  564.  
  565.     Purpose              :  General identification of system that
  566.                             includes all information to generate a St.
  567.                             Louis-format nodelist entry.
  568.  
  569.     SPECIFIC_DATA        :  system_name,
  570.                             city,
  571.                             operator_name,
  572.                             phone_number,
  573.                             baud_rate,
  574.                             flags:            ASCII2;
  575.  
  576.  
  577.         SYSTEM_NAME         The name of the system given by the user.
  578.                             This would normally be a company name, BBS
  579.                             name or other identifying text.
  580.  
  581.         CITY                The geographical location of the system.
  582.  
  583.         OPERATOR_NAME       The name of the person primarily responsible
  584.                             for the system.
  585.  
  586.         PHONE_NUMBER        The telephone number of the system, or
  587.                             "-Unpublished-" if the telephone number is
  588.                             unpublished. This MUST be in the standard
  589.                             format COUNTRY-CITY-NUMBER. Leading zeros
  590.                             should be stripped from the city code,
  591.                             ie. Stockholm (Sweden) has a city code of 08,
  592.                             included in an EMSI packet, it would read
  593.                             46-8-<number>.
  594.  
  595.         BAUD_RATE           The maximum baud rate supported by the
  596.                             system. This is NOT necessarily the same as
  597.                             the highest DTE rate.
  598.  
  599.         FLAGS               The St. Louis (FTSC) nodelist flags
  600.                             associated with the system.
  601.  
  602.  
  603.     PART III - Interactive Electronic Mail Standard Idenfitication
  604.  
  605.     Connecting two IEMSI capable systems
  606.     ═════════════════════════════════════════════════════════════════════
  607.     Two specific labels are used when discussing the IEMSI definitions.
  608.     The Client, which in this case is the Terminal software, and the
  609.     Server, which in this case is the interactive on-line software,
  610.     such as a BBS package or database system. It is assumed that the
  611.     Client and the Server have established a data link and that no
  612.     data has been transmitted by the Server.
  613.  
  614.     STEP 1, IEMSI INIT    
  615.  
  616.     There is no specific sequence of events in the IEMSI definition. The
  617.     Client must monitor incoming data and if the EMSI_IRQ sequence is
  618.     detected, it attempts to negotiate an IEMSI session with the Server.
  619.     Under no circumstances is the Client allowed to transmit an EMSI_ICI
  620.     packet prior to receiving the EMSI_IRQ sequence from the Server.
  621.     All IEMSI sequences and EMSI sequences used during an IEMSI session
  622.     are terminated by a single <CR>. There are no exceptions to this.
  623.  
  624.  
  625.     STEP 2A, Server
  626.  
  627.     ┌─┬──────────────────────────────────────────────────────────────────┐
  628.     │1│ Tries=0, T2=60 seconds                                           │
  629.     ├─┼──────────────────────────────────────────────────────────────────┤
  630.     │2│ Transmit EMSI_IRQ sequence                                       │
  631.     ├─┼──────────────────────────────────────────────────────────────────┤
  632.     │3│ T1=20 seconds, increment Tries                                   │
  633.     │ │                                                                  │
  634.     │ │ Tries>3?                        Discontinue IEMSI negotiation.   │
  635.     ├─┼──────────────────────────────────────────────────────────────────┤
  636.     │4│ Wait for EMSI_ICI packet until any of the timers have expired.   │
  637.     │ │                                                                  │
  638.     │ │ If T2 has expired, discontinue IEMSI negotiation.                │
  639.     │ ├──────────────────────────────────────────────────────────────────┤
  640.     │ │ If T1 has expired, go to step 2.                                 │
  641.     │ ├──────────────────────────────────────────────────────────────────┤
  642.     │ │ If EMSI_ICI seen, go to step 5.                                  │
  643.     │ ├──────────────────────────────────────────────────────────────────┤
  644.     │ │ Go to step 4.                                                    │
  645.     ├─┼──────────────────────────────────────────────────────────────────┤
  646.     │5│ Receive EMSI_ICI packet                                          │
  647.     │ ├──────────────────────────────────────────────────────────────────┤
  648.     │ │ Packet received OK?             Transmit EMSI_ISI packet, and    │
  649.     │ │                                 go to step 6.                    │
  650.     │ ├──────────────────────────────────────────────────────────────────┤
  651.     │ │ Packet not received OK?         Transmit EMSI_NAK and go to step │
  652.     │ │                                 3.                               │
  653.     ├─┼──────────────────────────────────────────────────────────────────┤
  654.     │6│ Tries=0                                                          │
  655.     ├─┼──────────────────────────────────────────────────────────────────┤
  656.     │7│ T1=20 seconds, increment Tries                                   │
  657.     │ │                                                                  │
  658.     │ │ Tries>3?                        Discontinue IEMSI negotiation.   │
  659.     ├─┼──────────────────────────────────────────────────────────────────┤
  660.     │8│ Wait for EMSI_ACK/EMSI_NAK until any of the timers have expired. │
  661.     │ │                                                                  │
  662.     │ │ If T2 has expired, discontinue IEMSI negotiation.                │
  663.     │ ├──────────────────────────────────────────────────────────────────┤
  664.     │ │ If T1 has expired or EMSI_NAK received, transmit EMSI_ISI packet │
  665.     │ │ again and go to step 7.                                          │
  666.     │ ├──────────────────────────────────────────────────────────────────┤
  667.     │ │ If EMSI_ACK received, go to step 9.                              │
  668.     │ ├──────────────────────────────────────────────────────────────────┤
  669.     │ │ Go to step 8.                                                    │
  670.     ├─┼──────────────────────────────────────────────────────────────────┤
  671.     │9│ IEMSI session successfully established, exit.                    │
  672.     └─┴──────────────────────────────────────────────────────────────────┘
  673.  
  674.     The Server must monitor its incoming data channel for 'normal' data,
  675.     ie. data not transmitted as IEMSI sequences, to detect if the user is
  676.     attempting to log-in without the use of IEMSI. The only basic
  677.     restriction this imposes on the Server is that user names and/or IDs
  678.     may not start with the character '*' since all EMSI/IEMSI sequences
  679.     start with this character.
  680.  
  681.     All processing of the information in the EMSI_ICI packet must be done
  682.     after transmitting the EMSI_ISI packet and receiving two EMSI_ACK
  683.     sequences in return.
  684.  
  685.  
  686.     STEP 2B, Client
  687.  
  688.     Note that this assumes that the Client has seen the EMSI_IRQ sequence
  689.     transmitted by the Server and that the negotiation is ready to take
  690.     place.
  691.  
  692.     ┌─┬──────────────────────────────────────────────────────────────────┐
  693.     │1│ Tries=0, T2=60 seconds                                           │
  694.     ├─┼──────────────────────────────────────────────────────────────────┤
  695.     │2│ Transmit EMSI_ICI packet                                         │
  696.     ├─┼──────────────────────────────────────────────────────────────────┤
  697.     │3│ T1=20 seconds, increment Tries                                   │
  698.     ├─┼──────────────────────────────────────────────────────────────────┤
  699.     │5│ Tries>3 or T2 expired?            Discontinue IEMSI negotiation. │
  700.     │ ├──────────────────────────────────────────────────────────────────┤
  701.     │ │ If T1 has expired, go to step 2.                                 │
  702.     │ ├──────────────────────────────────────────────────────────────────┤
  703.     │ │ If EMSI_ISI seen, go to step 6.                                  │
  704.     │ ├──────────────────────────────────────────────────────────────────┤
  705.     │ │ Go to step 5.                                                    │
  706.     ├─┼──────────────────────────────────────────────────────────────────┤
  707.     │6│ Receive EMSI_ISI packet                                          │
  708.     │ ├──────────────────────────────────────────────────────────────────┤
  709.     │ │ Packet received OK?              Transmit EMSI_ACK packet twice, │
  710.     │ │                                  and go to step 7.               │
  711.     │ ├──────────────────────────────────────────────────────────────────┤
  712.     │ │ Packet not received OK?          Transmit EMSI_NAK and go to step│
  713.     │ │                                  3.                              │
  714.     ├─┼──────────────────────────────────────────────────────────────────┤
  715.     │7│ IEMSI session successfully established, exit.                    │
  716.     └─┴──────────────────────────────────────────────────────────────────┘
  717.  
  718.     All processing of the information in the EMSI_ISI packet must be done
  719.     after transmitting two EMSI_ACK sequences in return.
  720.  
  721.     If either of the ICI or ISI packets are NAK'd three consecutive times,
  722.     the session negotiation attempt is terminated and the Client proceeds
  723.     as it would have done should the Server not have supported IEMSI.
  724.  
  725.  
  726.     IEMSI packet and sequence definitions
  727.     ═════════════════════════════════════════════════════════════════════
  728.  
  729.     ═════════════════════════════════════════════════════════════════════
  730.     EMSI ACK                                        **EMSI_ACK<crc16><CR>
  731.     ─────────────────────────────────────────────────────────────────────
  732.     EMSI ACK is transmitted by either Client or Server as a positive
  733.     acknowledgement of the valid receipt of an IEMSI packet such as
  734.     EMSI_ISI and EMSI_ICI. During an IEMSI session, this sequence can,
  735.     however, be used as a positive acknowledgement for other IEMSI
  736.     packets. Redundant EMSI_ACK sequences should be ignored.
  737.  
  738.     ═════════════════════════════════════════════════════════════════════
  739.     EMSI NAK                                        **EMSI_NAK<crc16><CR>
  740.     ─────────────────────────────────────────────────────────────────────
  741.     EMSI NAK is transmitted by either Client or Server as a negative
  742.     acknowledgement of the valid receipt of an IEMSI packet such as
  743.     EMSI_ISI and EMSI_ICI. During an IEMSI session, this sequence can,
  744.     however, be used as a negative acknowledgement for other IEMSI
  745.     packets. Redundant EMSI_NAK sequences should be ignored.
  746.  
  747.     ═════════════════════════════════════════════════════════════════════
  748.     EMSI IRQ                                        **EMSI_IRQ<crc16><CR>
  749.     ─────────────────────────────────────────────────────────────────────
  750.     Similar to EMSI_REQ which is used by mailer software to negotiate a
  751.     mail session. IRQ identifies the Server as being capable of
  752.     negotiating an IEMSI session. When the Client detects an IRQ sequence
  753.     in its inbound data stream, it attempts to negotiate an IEMSI
  754.     session.
  755.  
  756.     ═════════════════════════════════════════════════════════════════════
  757.     EMSI IIR                                        **EMSI_IIR<crc16><CR>
  758.     ─────────────────────────────────────────────────────────────────────
  759.     The IIR (Interactive Interrupt Request) sequence is used by either
  760.     Client or Server to abort the current negotiation. This could be
  761.     during the initial IEMSI handshake or during other interactions
  762.     between the Client and the Server.
  763.  
  764.     ═════════════════════════════════════════════════════════════════════
  765.     EMSI ICI                             **EMSI_ICI<len><data><crc32><CR>
  766.     ─────────────────────────────────────────────────────────────────────
  767.     The ICI packet is used by the Client to transmit its configuration
  768.     and Server-related information to the Server. It contains Server
  769.     parameters, Client options, and Client capabilities.
  770.  
  771.     ═════════════════════════════════════════════════════════════════════
  772.     EMSI ISI                             **EMSI_ISI<len><data><crc32><CR>
  773.     ─────────────────────────────────────────────────────────────────────
  774.     The ISI packet is used by the Server to transmit its configuration
  775.     and Client-related information to the Client. It contains Server data
  776.     and capabilities.
  777.  
  778.  
  779.     ═════════════════════════════════════════════════════════════════════
  780.     EMSI ISM                             **EMSI_ISM<len><data><crc32><CR>
  781.     ─────────────────────────────────────────────────────────────────────
  782.     The ISM packet is used to transfer ASCII images from the Server to
  783.     the Client. These images can then be recalled by the Client when
  784.     the Server needs to display a previously displayed image. This will
  785.     be further described in future revisions of this document.
  786.  
  787.     ═════════════════════════════════════════════════════════════════════
  788.     EMSI CHT                                        **EMSI_CHT<crc16><CR>
  789.     ─────────────────────────────────────────────────────────────────────
  790.     The CHT sequence is used by the Server to instruct the Client
  791.     software to enter its full-screen conversation mode function (CHAT).
  792.     Whether or not the Client software supports this is indicated in the
  793.     ICI packet.
  794.  
  795.     If the Server transmits this sequence to the Client, it must wait for
  796.     an EMSI_ACK prior to engaging its conversation mode. If no EMSI_ACK
  797.     sequence is received with ten seconds, it is safe to assume that the
  798.     Client does not support EMSI_CHT. If, however, an EMSI_NAK sequence
  799.     is received from the Client, the Server must re-transmit the
  800.     EMSI_CHT sequence. Once the on-line conversation function has been
  801.     sucessfully activated, the Server must not echo any received
  802.     characters back to the Client.
  803.  
  804.     ═════════════════════════════════════════════════════════════════════
  805.     EMSI TCH                                        **EMSI_TCH<crc16><CR>
  806.     ─────────────────────────────────────────────────────────────────────
  807.     The TCH sequence is used by the Server to instruct the Client
  808.     software to terminate its full-screen conversation mode function
  809.     (CHAT).
  810.  
  811.     If the Server transmits this sequence to the Client, it must wait for
  812.     an EMSI_ACK prior to leaving its conversation mode. If no EMSI_ACK
  813.     sequence is received with ten seconds, a second EMSI_TCH sequence
  814.     should be issued before the Server resumes operation. If, however, an
  815.     EMSI_NAK sequence is received from the Client, the Server must
  816.     re-transmit the EMSI_TCH sequence.
  817.  
  818.  
  819.     The EMSI_ICI packet
  820.     ═════════════════════════════════════════════════════════════════════
  821.     The following pseudo structure shows the layout of the EMSI_ICI
  822.     packet. Note that the information in the EMSI_ICI packet may not
  823.     exceed 2,048 bytes.
  824.  
  825.     EMSI_ICI
  826.         name,
  827.         alias,
  828.         location,
  829.         data#,
  830.         voice#,
  831.         password,
  832.         birthdate,
  833.         crtdef,
  834.         protocols,
  835.         capabilities,
  836.         requests,
  837.         software,
  838.         xlattabl:                ASCII1;
  839.     end;
  840.  
  841.     EMSI_ICI field definitions
  842.     ─────────────────────────────────────────────────────────────────────
  843.     
  844.     ═════════════════════════════════════════════════════════════════════
  845.     Name and Alias (or Handle)
  846.     ─────────────────────────────────────────────────────────────────────
  847.     The name and possible alias (AKA) of the user (Client). This must be
  848.     treated case insensitively by the Server.
  849.  
  850.     ═════════════════════════════════════════════════════════════════════
  851.     Location
  852.     ─────────────────────────────────────────────────────────────────────
  853.     The geographical location of the user, ie. Stockholm, Sweden.
  854.  
  855.     ═════════════════════════════════════════════════════════════════════
  856.     data# and voice#
  857.     ─────────────────────────────────────────────────────────────────────
  858.     Unformatted data and voice telephone numbers of the user. Unformatted
  859.     is defined as the full telephone number, including country and local
  860.     area code. Eg. 46-8-90510 is a telephone number in Stockholm, Sweden.
  861.  
  862.     ═════════════════════════════════════════════════════════════════════
  863.     Password
  864.     ─────────────────────────────────────────────────────────────────────
  865.     The password for the user. This must be treated case insensitively by
  866.     the Server.
  867.  
  868.  
  869.     ═════════════════════════════════════════════════════════════════════
  870.     Birthdate
  871.     ─────────────────────────────────────────────────────────────────────
  872.     Hexadecimal string representing a long integer containing the birth-
  873.     date of the user in UNIX notation (number of seconds since midnight,
  874.     Jan 1 1970). This must be treated case insensitively by the Server.
  875.  
  876.     ═════════════════════════════════════════════════════════════════════
  877.     CrtDef
  878.     ─────────────────────────────────────────────────────────────────────
  879.     Consisting of four sub-fields separated by commas, this field
  880.     contains from left to right: The requested terminal emulation
  881.     protocol, the number of rows of the user's CRT, the number of columns
  882.     of the user's CRT, and the number of ASCII NUL (00H) characters the
  883.     user's software requires to be transmitted between each line of text.
  884.  
  885.     The following terminal emulation protocols are defined:
  886.  
  887.         AVT0    AVATAR/0+. Used in conjunction with ANSI. If AVT0 is
  888.                 specified by the Client, support for ANSI X3.64 emulation
  889.                 should be assumed to be present.
  890.         ANSI    ANSI X3.64
  891.         VT52    DEC VT52
  892.         VT100   DEC VT100
  893.         TTY     No terminal emulation, also referred to as RAW mode.
  894.  
  895.     ═════════════════════════════════════════════════════════════════════
  896.     Protocols
  897.     ─────────────────────────────────────────────────────────────────────
  898.     The file transfer protocol option specifies the preferred method of
  899.     transferring files between the Client and the Server in either
  900.     direction. The Client presents all transfer protocols it is capable
  901.     of supporting and the Server chooses the most appropriate protocol.
  902.  
  903.         DZA*    DirectZAP (Zmodem variant)
  904.         ZAP     ZedZap (Zmodem variant)
  905.         ZMO     Zmodem w/1,024 byte data packets
  906.         SLK     SEAlink
  907.         KER     Kermit
  908.     
  909.     (*) DirectZAP is a variant of ZedZap. The difference is that the
  910.     transmitter only escapes CAN (18H). It is not recommended to use the
  911.     DirectZAP protocol when the Client and the Server are connected via a
  912.     packet switching network, or via another layer sensitive to control
  913.     characters such as XON and XOFF.
  914.  
  915.  
  916.     ═════════════════════════════════════════════════════════════════════
  917.     Capabilities
  918.     ─────────────────────────────────────────────────────────────────────
  919.     The capabilities of the user's software. If more than one capability
  920.     is listed, each capability is separated by a comma.
  921.  
  922.     The following capability codes are defined:
  923.  
  924.         CHT     Can do full-screen on-line conversation (CHAT).
  925.         MNU     Can do ASCII image download (see ISM packet).
  926.         TAB     Can handle TAB (ASCII 09H) characters.
  927.         ASCII8  Can handle 8-bit IBM PC ASCII characters.
  928.  
  929.     ═════════════════════════════════════════════════════════════════════
  930.     Requests
  931.     ─────────────────────────────────────────────────────────────────────
  932.     The requests field specifies what the user wishes to do once the
  933.     initial IEMSI negotiation has been successfully completed. If more
  934.     than one capability is listed, each capability is separated by a
  935.     comma.
  936.  
  937.     The following request codes are defined:
  938.  
  939.         NEWS    Show bulletins, announcements, etc.
  940.         MAIL    Check for new mail.
  941.         FILE    Check for new files.
  942.         HOT     Hot-Keys.
  943.         CLR     Screen clearing.
  944.         HUSH    Do not disturb.
  945.         MORE    Page pausing, often referred to as "More".
  946.         FSED*   Full-screen editor.
  947.         XPRS    <reserved>.
  948.  
  949.     (*) Note that this allows the Client to request use of a full-screen
  950.     editor without requiring that it also supports a full-screen terminal
  951.     emulation protocol.
  952.  
  953.     ═════════════════════════════════════════════════════════════════════
  954.     Software
  955.     ─────────────────────────────────────────────────────────────────────
  956.     The name, version number, and optionally the serial number of the
  957.     user's software. Eg. {FrontDoor,2.00,AE000001}.
  958.  
  959.     ═════════════════════════════════════════════════════════════════════
  960.     XlatTabl
  961.     ─────────────────────────────────────────────────────────────────────
  962.     Used for character translation between the Server and the Client.
  963.     This field has not been completely defined yet and should always be
  964.     transmitted as {} (empty).
  965.  
  966.  
  967.     The EMSI_ISI packet
  968.     ═════════════════════════════════════════════════════════════════════
  969.     The following pseudo structure shows the layout of the EMSI_ISI
  970.     packet. Note that the information in the EMSI_ISI packet may not
  971.     exceed 2,048 bytes.
  972.  
  973.     EMSI_ISI
  974.         id,
  975.         name,
  976.         location,
  977.         operator,
  978.         localtime,
  979.         notice,
  980.         wait,
  981.         capabilities:            ASCII1;
  982.     end;
  983.  
  984.     EMSI_ISI field definitions
  985.     ─────────────────────────────────────────────────────────────────────
  986.     
  987.     ═════════════════════════════════════════════════════════════════════
  988.     ID
  989.     ─────────────────────────────────────────────────────────────────────
  990.     The name, version number, and optionally the serial number of the
  991.     Server software. Eg. {RemoteAccess,1.10/b5,CS000001}.
  992.  
  993.     ═════════════════════════════════════════════════════════════════════
  994.     Name
  995.     ─────────────────────────────────────────────────────────────────────
  996.     The name of the Server system. Eg. {Advanced Engineering S.A.R.L.}.
  997.  
  998.     ═════════════════════════════════════════════════════════════════════
  999.     Location
  1000.     ─────────────────────────────────────────────────────────────────────
  1001.     The geographical location of the user, ie. Stockholm, Sweden.
  1002.  
  1003.     ═════════════════════════════════════════════════════════════════════
  1004.     Operator
  1005.     ─────────────────────────────────────────────────────────────────────
  1006.     The name of the primary operator of the Server software. Eg. {Joaquim
  1007.     H. Homrighausen}.
  1008.  
  1009.  
  1010.  
  1011.     ═════════════════════════════════════════════════════════════════════
  1012.     Localtime
  1013.     ─────────────────────────────────────────────────────────────────────
  1014.     Hexadecimal string representing a long integer containing the current
  1015.     time of the Server in UNIX notation (number of seconds since midnight,
  1016.     Jan 1 1970). This must be treated case insensitively by the Client.
  1017.  
  1018.     ═════════════════════════════════════════════════════════════════════
  1019.     Notice
  1020.     ─────────────────────────────────────────────────────────────────────
  1021.     May contain copyright notices, system information, etc. This field
  1022.     may optionally be displayed by the Client.
  1023.  
  1024.     ═════════════════════════════════════════════════════════════════════
  1025.     Wait
  1026.     ─────────────────────────────────────────────────────────────────────
  1027.     A single character used by the Server to indicate that the user
  1028.     has to press the <Enter> key to resume operation. This is used in
  1029.     conjunction with ASCII Image Downloads (see ISM packet).
  1030.  
  1031.     ═════════════════════════════════════════════════════════════════════
  1032.     Capabilities
  1033.     ─────────────────────────────────────────────────────────────────────
  1034.     The capabilities of the Server software. No Server software
  1035.     capabilities have currently been defined.
  1036.  
  1037.     Credits and other notes
  1038.     ═════════════════════════════════════════════════════════════════════
  1039.     The original EMSI specifications were designed by Chris Irwin and
  1040.     Joaquim H. Homrighausen. The original IEMSI specifications were
  1041.     designed by Joaquim H. Homrighausen and Andrew Milner.
  1042.  
  1043.     --- end of "emsi.doc" ---
  1044.  
  1045.